Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ScrollView observes and adjusts for keyboard position #55

Merged
merged 5 commits into from
Apr 1, 2020

Conversation

kyleve
Copy link
Collaborator

@kyleve kyleve commented Feb 17, 2020

This PR makes ScrollView smart about observing the position of the system keyboard. When the keyboard is displayed, updated, or dismissed, the ScrollView will adjust its contentInset.bottom to account for the updated inset. This is done through KeyboardObserver, which is an object to observe and manage keyboard positioning, which I've copied over from Listable. I've also added keyboardDismissMode to ScrollView in this PR, allowing management of keyboard dismissal in ScrollView instances.

@kyleve kyleve changed the title [WIP] ScrollView observes the keyboard ScrollView observes and adjusts for keyboard position Feb 23, 2020
@kyleve
Copy link
Collaborator Author

kyleve commented Feb 26, 2020

Pushed some, but not all requested changes, will get to those later.

This update also includes changes to how we manage contentInset overall, because the provided ScrollView.contentInset and the keyboard's bottom inset needed to play nicer together. This updates ensures we continue using ScrollView.contentInset.bottom alongside the additional inset from the keyboard. Also centralized calculation of the final inset to one place.

@kyleve kyleve force-pushed the kve/keyboard-observation branch from ff932db to d42c5c1 Compare February 26, 2020 20:34
@kylebshr
Copy link
Contributor

kylebshr commented Mar 5, 2020

Could you verify this isn't also an issue with the implementation here?

@bizzemfrog
Copy link

any movement on this?

@kyleve
Copy link
Collaborator Author

kyleve commented Mar 21, 2020

Nope... can try to look soon.

@kyleve
Copy link
Collaborator Author

kyleve commented Mar 23, 2020

Could you verify this isn't also an issue with the implementation here?

Doesn't seem to be an issue from testing

EDIT: Spoke too soon.. wasn't seeing this on iphone, but it is happening on ipad. Will fix.

@kyleve
Copy link
Collaborator Author

kyleve commented Mar 25, 2020

This should be good for another review.

@kyleve kyleve force-pushed the kve/keyboard-observation branch from 175a19b to 141eabf Compare March 30, 2020 22:23
kyleve added 2 commits March 30, 2020 15:33
* master:
  Releasing 0.7.0
  Fix comment about extraSize
  ASCII diagrams in stack layout
  Measure stack axes separately
  A better workaround for missing dylibs
  Workaround for libswiftsimd.dylib not being copied
  Bump CocoaPods version
  Update to Xcode 11 and Swift 5.1
  Remove iOS 10 availability checks
  Raise the minimum iOS version to 10
  Releasing 0.6.0
  Don't apply keyboardDismissMode unless it changed
  Change property from Bool to UIScrollView.KeyboardDismissMode and pass it directly
  Allow ScrollView to dismiss the keyboard on tap
self.center = center

/// We need to listen to both `will` and `keyboardDidChangeFrame` notifications. Why?
/// When dealing with an undocked or floating keyboard, moving the keyboard
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What actually happens with an undocked keyboard? We don't want to treat it as a bottom content inset in those cases, do we? e.g. if the keyboard is floating near the top of the screen, we should probably just leave the content offset alone.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went back and forth on this... there's four forms of keyboards:

  1. Docked, takes up full width
  2. Undocked, takes up full width
  3. Also undocked, split, also semantically is full width
  4. Floating on iPad, does not take up full width

I figured we generally want this for the first three cases, so kept it simple for now. I'll follow up with something for #4, to not inset in this case?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#71


extension KeyboardObserver
{
struct NotificationInfo : Equatable {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

private?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs to be internal for testing access.


private extension UIView {

var bp_safeAreaInsets : UIEdgeInsets {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Smells like Obj-C. How about a name like polyfillSafeAreaInsets?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather keep this as is... It's clear to developers from patterns what this means.

// MARK: Keyboard
//

private func updateBottomContentInsetWithKeyboardFrame() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is almost the same func as applyContentInset, can they merge?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doh, will do

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to dig into this more... there's a bit of nuanced behaviour between the logic in applyContentInset handling changes only from the model updates, vs updateBottomContentInsetWithKeyboardFrame always updating on live views.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to leave as is for now and come back to this one.


Note: When `keyboardAdjustmentMode` is used, it will also adjust
the on-screen `UIScrollView`s `contentInset.bottom` to make space for the keyboard.
*/
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 for comments!

BlueprintUICommonControls/Sources/ScrollView.swift Outdated Show resolved Hide resolved
@kyleve kyleve force-pushed the kve/keyboard-observation branch from 7a5a39b to 95633fd Compare March 31, 2020 01:27
@kyleve kyleve merged commit 120dff5 into master Apr 1, 2020
@watt watt deleted the kve/keyboard-observation branch November 24, 2021 02:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants